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MUTUAL EXCLUSION AT THE RECORD Present operating systems typically employ mutual exclu- 

LEVEL WITH PRIORITY INHERITANCE sioa schemes that include one or more of the following 

FOR EMBEDDED SYSTEMS USING ONE mechanisms: semaphores, mutexes, or preemption locks. 

SEMAPHORE Each of these mechanisms possess disadvantages that limit 

5 their utility in real-time embedded system applications. 
Basic mutual exclusion systems use semaphores, which 

FIELD OF THE INVENTION ggg^ ^^^j ^ programs to coordinate the activities of 

The present invention relates generally to computer i°ore than one program or routine. Since one semaphore is 

software, and more specifically to providing efficient mutual required for each routine or resource that is to be protected, 

exclusion of multiple tasks in an embedded system. ^° ^sc of seniaphorcs may require significant memory 

usage. In certain applications, the number of semaphores 

BACKGROUND OF THE INVENTION may be limited in number by the operating system. For 

Real time embedded software applications are often example some operating systems provide a limited number 

divided into individual tasks that execute independently. la semaphores, and may not be designed to work well m an 

typical appUcations, these tasks operate on data that is global environment where many thousands would be required for 

to the application, or to more than one of the application's record-level locking. 

tasks. Global data is often organized into groupings of like Mutexes are similar to semaphores but are related to the 

records. Each record is a data structure that represents a ^se of operating system threads. Therefore implementation 

collection of fields or elements. Global data may consist of of "»»itual exclusion through mutexes requires the applica- 

thousands of records, each representing an instance of ^io" ^ threads rather than tasks. Since threads, and 

something the appUcation must manage. To ensure data therefore mutexes, are not universally supported by all 

integrity and proper operation of the application, access to operating systems, appHcability of this approach is limited, 

one record must not interfere in any way with access to any Moreover, mutexes generally exhibit the same memory 

other record. In systems in which one task is preempted in usage disadvantages as semaphores, 

order to allow another task to mn, the probability of data Preemption locks are used to prevent a current task from 

corruption and/or race conditions occurring is often unac- being preempted during a critical region. This mechanism 

ceptably high. To prevent these conditions from arising, basically elevates the task with a lock to the highest possible 

some form of mutual exclusion is required. priority. In a real time environment, this is generally 

In distributed processing and other multi-user or multi- 30 unacceptable, as a very low priority task can prevent a high 

task applications, record locking is used to control reading priority task from mnning for a significant amount of time, 

data from or writing data to a record. A mutual exclusion and embedded systems typically require that critical system 

record locking mechanism helps to ensure that only one events be processed with as littte delay as possible, 

program or routine at a time can access a record. In general, SUMMARY AND OBJECTS OF THE 

multiple read locks on a record are allowed simultaneously, 35 INVENTION 
while only one write lock per record is permitted at any one 

time. A read lock must be refused if another task has a write of the objects of the present invention is to provide 
lock on a record, and vice versa. Thus, both read locks and » n^^^^l exclusion mechanism that allows read/wnte lock- 
write locks are record accesses, f^^ord level. 

Because of performance considerations, real time embed- 40 Another of the objects of the present invention is to 

ded software applications impose strict requirements on provide a mutual exclusion mechanism that provides record 

mutual exclusion mechanisms. For example, a mutual exclu- locking with mmimal memory and processor bandwidth 

sion mechanism cannot consume significant memory, nor requirements. 

can it impose a significant amount of processing overhead. A further object of the present invention is to provide a 

Although actual requirements vary in terms of the available 45 record locking mechanism that both detects and prevents 

memory and processing power of the system, the mecha- deadlock. 

nism must in general not be wasteful. In one embodiment of the present invention, a method of 

Furthermore, in most applications, the mutual exclusion providing mutual exclusion at a single data element level for 

mechanism must support priority inheritance. If a low pri- use in embedded systems is described. Entries for tasks that 

ority task holds a resource, and a higher priority task 50 are currently holding a resource are stored in a hold list, 

requests that resource, the priority of the low priority task Entries for tasks that are not currently executing and are 

should be elevated to that of the high priority task until it waiting for resources to be freed are stored in a wait list. A 

task releases the resource. Once the resource is released, single mutual exclusion semaphore synchronize any request 

priorities should revert to their original levels. In general, it to access a resource. 

is also desirable for the mutual exclusion mechanism to be 55 Other objects, features, and advantages of the present 

able to detect and/or prevent deadlock. In a multi-tasking invention will be apparent from the accompanying drawings 

environment several tasks may compete for a finite number and from the detailed description that follows below, 

of tesoutces. A t^k requests resources; if the resources arc gj^,gp oESCRIPnON OF TOE DRAWINGS 
not available at that time the tasks enters the wait state. It 

may happen that waiting tasks will never again change state, 60 ^h^ present invention is illustrated by way of example 

because the resources they have requested are held by other limitation in the figures of the accompanying 

waiting tasks. This situation is caUed deadlock. For example, drawings, in which like references indicate similar elements, 

deadlock occurs when a first task requests a record held by ^nd in which: 

a second task while the second task is simultaneously FIG. 1 is a block diagram of a computer system that is 

requesting a record held by the first task. The result is neither 65 used to implement embodiments of the present application, 

task has its request answered. Such an occurrence could FIG. 2 illusU-ates the structure and organization of a wait 

cause the application program or system software to crash. list, according to one embodiment of the present invention. 
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FIG. 3 illustrates the structure and oiganization of exem- 
plary record group bold lists, according to one embodiment 
of the present invention. 

FIG. 4 is a flowchart that lists the steps of locking a single 
resource, according to one embodiment of the present inven- 
tion. 

FIG. 5 is a flowchart that illustrates the steps of accessing 
a held resource, according to one embodiment of the present 
invention. 

FIG. 6 is a flowchart that illustrates the steps of locking 
multiple resources, according to one embodiment of the 
present invention. 

FIG. 7 is a flowchart that illustrates the steps of locking 
multiple resources in which a referenced resource cannot be 
locked, according to one embodiment of the present inven- 
tion. 

DETAILED DESCRIPTION 

A system is described that provides mutual exclusion of 
multiple tasks at the record level with priority inheritance 
and using one semaphore. 

FIG. 1 is a block diagram of a representative computer 
system that is used to implement the mutual exclusion 
mechanism of an embodiment of the present invention. The 
computer system 100 includes a processor 102 coupled 
through a bus 101 to a random access memory (RAM) 104, 
a read only memory (ROM) 106, and a mass storage device 
107. Mass storage device 107 is typically implemented as a 
disk or tape drive for storing data and instructions. A display 
device 121 for providing visual output is also coupled to 
processor 102 through bus 101. Keyboard 122 is coupled to 
bus 101 for communicating information and command 
selections fix)m the user to processor 102. Another type of 
user input device is cursor control unit 123, which may be 
a device such as a mouse or trackball, for communicating 
direction commands that control cursor movement on dis- 
play 121. 

It is to be noted that the architecture of FIG. 1 is provided 
only for purposes of illustration, and that a computer system 
that implements embodiments of the present invention is not 
limited to the specific architecture shown. 

In one embodiment of the present invention, computer 
system 100 represents an embedded system. In general, an 
embedded system is a special-purpose computer that is 
incorporated within or controlled by a machine or other type 
of equipment. Embedded systems are typically used to 
execute real-time applications that include multiple tasks 
that require deterministic access to system resources. Real 
time applications thus typically require very fast context 
switch times among the various tasks and resources that are 
accessed and managed by the applications. Furthermore, 
these applications are typically executed by embedded sys- 
tems that are used in low-cost or low-power applications, 
and thus feature limited memory and/or processor resources. 
Thus, embedded systems are characterized by high perfor- 
mance and low resource utilization requirements. 

Embedded system software applications or programs are 
generally organized into tasks. Each task is an independent 
or nearly independent entity that accesses one or more 
system databases. In a typical embedded system, the system 
databases are accessed by multiple tasks. Data within the 
databases may be organized in various different ways. In 
general, the fundamental unit within a database is referred to 
as a "record". A record is a data structiurc that consists of a 
number of sub-elements (or fields), each with its own name 
and type. A group of like records can be organized into a 
record group. The application data generally comprises all 
records groups (and thus all the data) maintained by a 
software application. 
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In one embodiment of the present invention, the system is 
configured to treat each entity, such as a record or record 
group, as a resource. Each resource therefore represents a 
logical entity for which mutual exclusion is required to be 

^ provided. In one embodiment of the present invention, 
locking is provided at any resource level. Thus, locking is 
possible at the record level, record group level, application 
data level, or any other level. 

In one embodiment of the present invention, two lists are 
maintained within the system. One list is referred to as the 
"wait list" and contains a list of tasks that are not currently 
executing and are waiting for a resource to be freed. The 
second list is referred to as the "hold list" and contains a list 
of tasks that are currently holding a reso\u-ce (e.g., a record). 
These queued lists are used to implement priority inherit- 

35 ance and deadlock prevention within the embedded system 
applications. 

In one embodiment of the present invention, a semaphore 
is used to ensure the integrity of the wait list and, the hold 
list. In order to achieve this, any request to lock or imlock a 

20 resource is encapsulated within a mutual exclusion sema- 
phore. In one embodiment of the present invention, only one 
semaphore is used for both the wait list and hold list. In an 
alternative embodiment of the present invention, more than 
one semaphore is used. For example, one semaphore may be 

25 used with the hold list, and a second semaphore may be used 
with the wait list, or multiple semaphores may be used 
depending on the number of tasks or record groups. 

In one embodiment of the present invention, the wait list 
is a static list of entries, with one entry per task. This 
corresponds to the fact that each task can only wait for one 
resource at a time. FIG. 2 iUustrates the structure and 
organization of a wait list, according to one embodiment of 
the present invention. In FIG. 2, wait list 200 contains N task 
entries, labeled tasks 1 to N, Each task in the list is a task that 
is not currently executing and is waiting for a resource to be 
freed. The tasks entries are queued in the order of priority to 
receive the next free resource. Thus, task 1 is of hi^er 
priority than task 2, and so on down to task N. 

The second list is the hold list. In one embodiment of the 
present invention, the hold list is a dynamic list organized by 

^ record groups. For each record group there is a linked list of 
resources that are currently held by a task. As defined earlier, 
resources can be records, record groups or all application 
data. A task can be waiting for or be holding any of these 
resource types. In the case where a task is holding a record 

45 group, an element in the linked list indicates all resources of 
this record group. 

FIG. 3 illustrates the structure and organization of exem- 
plary record group hold lists, according to one embodiment 
of the present invention. In FIG. 3, n different lists are 

50 maintained for n different resource types denoted Resource 
Type RTl to Resource RTn. Each resource type list includes 
entries for each of the held resources for that resource type. 
Thus, for the example illustrated in FIG. 3, the hold list for 
Resource Type 1, 302, contains three resources denoted 

J J Resourcel, Resource2, and Resource3; the hold list for 
Resource Type 2, 304, contains all of the type 2 resources; 
the hold list for Resource Type 3, 306, contains two entries, 
one for some of the type 3 resources and another for a 
specific type 3 resource; and the hold list for Resource Type 
n, 308 contains two type n resources denoted Resourcel and 

^0 Resource2. The hold list also includes a prioritized listing of 
tasks that hold the resources. Several items of information 
about the tasks is included in this list, such as task name, 
current priority level, original priority level, and other such 
information. 

65 In one embodiment of the present invention, the wait list 
and hold list are data structures that are maintained in the 
system memory, such as random access memory 104 in FIG. 
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1. Entries within the two lists are modified or updated by the resource quickly. Priority inheritance also prevents pre- 

embedded system application or by specialized tasks within emptioo of the second task by a third task. For example, by 

the operating system. In an alternative embodiment of the inheriting task A's priority level, task B will not get pre- 

present invention, the wait Ust and hold list are maintained ^^^^ ^ ^ ^^sk ("task C), where task C has a lower 
m non-yolatile memory, such as niass storage device 107 or 5 priority than task A but a higher level than task B's original 

other similar memory, such as a flash memory device. f , , u • i_ t. • . 1 ^ 

... ^ . . . / 1®^^^- Without such pnonty mhentance mechanism, task C 

It IS important to note that organizing the embedded ^^^1^ allowed to run indefinitely without allowing task A 

system by tasks waiUng for a resource to be freed (e.g.. as ^^^^^^ ^^^^^ temporarily held by task B 

shown m FIG. 1) and/or resources accordmg to resource f j j 

held for specific resource types (e.g., as shown in FIG. 2) In one embodiment of the present invention, a mechanism 

results in efficient memory usage. That is, memory usage is is implemented to prevent deadlock between two or more 

mostly a function of only the number of waiting tasks and/or tasks of the embedded system application. In one embodi- 

resource types currently utilized within the system. The ment of the present invention, a single lock mechanism is 

memory consumed is therefore typically less than other implemented. In the single lock method, a task is allowed to 

approaches that, for example, simply store the entire Ubrary only one resource at any given time. The single lock 

of all system resources within memory. „jeti,od is relatively simple to implement and incuis rela- 

Single Record Locking lively little overhead since it involves only a restriction on 

The following discussion describes the events that occur the resource holding capabilities of each task, 

during various resource locking situations using the wait and , , , 

hold lists. The simplest situation occurs in which a task alternative embodiment of the present mvention a 

attempts to lock a free resource. In one embodiment of the "P^^^P^^ lock with pnority mechanism is implemented. In 

presem invention, an attempt to lock a free resource simply multiple lock method, each task is aUowed to hold 

results in the resource being added to the hold Ust for the multiple resources. ITie tasks acquire the resources in a 

requesting task. Thus, when task A attempts to lock a specified order and maintain the priority level of these 

resource, and there is no entry in the hold list indicating it resources. The multiple lock method overcomes some of the 

is held by another task, then the resource is added to the hold restrictions of the single lock method and accommodates the 

list and task A continues to execute. Likewise, when a task processing of separate records that are linked or related, and 

frees a resource, and no other task is waiting for the that must be processed together, 

resource, the task continues to execute and the resource ^.i^,,- 

becomes a free resource. Another related embodiment concerns multiple read and 
. 1- . J u . 1 .in single write functionality. That is, if a task requires a 

A more comphcated situation occurs when a task attempts ^^JZ„^^^ ^^r^u. u tuJ* ,0 

to lock a held resource. Thus, if a first task ("task A") "^^'^^^ '^'^ ^""^ ^^^^ l'"^^ ^ 

attempts to lock a resource, and the resource is already held "°de^omg a wnte access, the read request is granted 

by a second task ("task B"), three main events occur. First, regardless of the number of other tasks also reading or 

task A is added to the wait list; second, task A is suspended; requestmg to read the resource. Thus mukiple reads are 
and third, the priority of task A is compared against the 35 permissible provided no write access is occumng. Write 

priority of task B so that the priority of task B may be shifted access must maintain mutual exclusion of the resource, 

accordingly. however. Thus, write access is granted only if there is no 

HG. 4 is a flowchart that lists the steps of locking a held present read or write access concenaing the resource, 
resource according to one embodiment of the present inven- Another embodiment envisions deadlock detection as 
tion. As described above, it is assumed that task A is 40 opposed to deadlock prevention. As deadlock is not sup- 
attempting to lock a resource held by task B. In step 402 an po^ed to occur, deadlock detection functionality is ideally 
entry for task A is written to the wait hst. Execution of task j^^^^ed only in situations where design ground rules have 
A IS then suspended, step 404. In step 406, the current ^^^^ ^n^^^^ ^ development engineering 
pnority 01 task A is compared to the current pnonty of task x 1. *i_ * j ji 1 * n • 
B. In step 408 it is determined whether the priority of task 45 error) such that a deadlock actuaUy occurs. Thus m one 
A is higher than the priority of task B. If the priority of task ' e°ibod"°ent. if deadlock occurs, the system may waive 
A is higher than the cunent priority of task B, then task B's "^^^ual exc usion pohcy and simply grant multiple access, 
priority is elevated to that of task A, and the cuaent priority Subsequently, a system error is reported and a record is 
of task B in the hold Hst is updated to reflect the new priority c^^^^ed listmg the tasks and resources associated with the 
level, step 410. Once task B inherits the priority of task A, deadlock, 
task B continues to execute, step 412. Multiple Record Locking 

no. 5 is a flowchart that illustrates the steps of accessing general, software applications operate on many differ- 

a held resource, according to one embodiment of the present ent resources. In many cases, resources are related, so that 

invention. For the discussion of HG. 5, it is assum^^ the application may need to operate on two or more 

tasks frees a resource that task A IS waitmg for ^ ^^^^^^^^^ embodiment of the 

task B frees the resource. Next, the pnonty of task B is set ™c.o«f ;«„o«»,v.« « c^i,^^,^ i^^i^^^^f^A tu^ 

, • ■ , 1 f I. • ; etxA 1 A • .1. present invention, a scheme is implemented that allows the 

to lis original, or default, pnonty, step 504. Task A is then 1- . 1 1 u- 1 . 

removed from the wait step S06. In step 508. execution m}'<^'^°° multiple resources at one Ume and to 

of task A is resumed. derive a reference from one resource to another For 

... example, if a first resource ("resource X 0 contains a data 

As descnbed above, in one embodiment of the present ^Ur„I„f tu^t « ^«f«.-«»r.« t\ « ^^^r^r.A 

■* • u u i_ !- 60 element tnat is a reference to a second resource ( resource 

mvention, a pnonty mhentance scheme between two or °" v«\ .u *u ^ i.- i -j i i * u • « .u 

more tasks is implemented. For example, in step 410 of HG. ^ >^'^^" multiple record loclang mechanism aUows the 

4. the current priority level of task B is shifted to that of task "PPl'^tw" 1°* both resource X and resource Y based on 

A. This priority inheritance mechanism is facilitated by the ^"''y * reference to resource X. 

storage of each tasks' current and original priority in the In the following discussion, it is assumed that there are 
hold list. The inheritance of a higher priority level by a lower 65 two threads of logic in the application code. For example, 

priority task helps to ensure that the second task (the original the first thread of logic may be represented in computer 

lower priority task) executes quickly, and thus releases the source code as follows: 
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1: for each (X) 
{ 

<operate on X> 

refeience Y based on an element in X 
<operate on Y> 

} 



Likewise, the second thread of logic may be represented in 
computer source code as foUows: 



2: for each (Y) 
{ 

<oper&te on Y> 

reference X based on an element in Y 
<operBte on X> 

} 



If these two logic threads (denoted "1" and "2") were 
contained in different tasks, deadlock might occur if logic 
thread 1 locked resource X and then resource Y, while logic 
thread 2 locked resource Y and then resource X. Thus, 
resources X and Y must be locked in the same order in both 
cases to ensure that deadlock does not occur. However in 
logic thread 1, resource Y is not known before referencing 
resource X, since resource X contains the reference to 
resource Y (and vice versa in logic thread 2). 

In one embodiment of the present invention, a mechanism 
is implemented to lock both resource X and resource Y to 
prevent such deadlock. In one embodiment, the multiple 
resource locking mechanism uses a list of resources to be 
locked (in this example, resources X and Y), a reference to 
resource X, and a method (function pointer) for deriving 
resource Y from resource X. 

It should be noted that the multiple locking mechanism 
according to one embodiment, does not require the resources 
to be related. The resources can be completely independent 
of one another. Using the example above, instead of pro- 
viding a method for deriving resource Y from resource X, an 
explicit reference to resource Y can be given in its place. 

In an alternative embodiment of the present invention, the 
multiple lock mechanism is extended to work with more 
than two resources. For example, if there is a third resource 
("resource Z") that is also referenced from X, it could also 
be locked at the same time. 

In one embodiment of the present invention, the resources 
are locked in a specific order of priority. For this 
embodiment, the resources are first separated into two lists. 
The first list includes references resources (i.e., resources for 
which a reference has been provided, for example X). The 
second list includes derived resources (i.e., resources that do 
not have a reference, for example Y). Each of these lists is 
then sorted in order of descending priority. 

FIG. 6 is a flowchart that illustrates the steps of locking 
multiple resources, according to one embodiment of the 
present invention. In step 602, the highest priority resource 
from the reference list is located. If this resource is not 
already locked by the requesting task, the resource is then 
locked, step 604. Once the highest priority resource is 
locked, the derived list is traversed to locate any resources 
that are referenced in this resource, step 606. Since the 
derived hst is sorted, the resources are examined from 
highest priority to lowest priority. For each referenced 
resource that is found, the system derives the resoitfce and 
then locks it, step 608. 

In step 610 it is determined whether the end of the derived 
list has been reached. If end of the derived list has not been 
reached, the method proceeds from step 606 in which the 



derived list is traversed to locate the next resource refer- 
enced by the highest priority task. When the end of the 
derived list is reached, the system finds the next highest 
priority resource from the reference list, step 612. The 

J method then continues from step 604 until all of the 
resources are processed. 

In certain circumstances, it may occur that a referenced 
resource cannot be locked. FIG. 7 is a flowchart that 
illustrates the steps of locking multiple resources in which a 
referenced resource cannot be locked, according to one 

30 embodiment of the present invention. In the following 
discussion, it is assumed that a first resource ("resource R") 
cannot be locked. In step 702 the system unlocks all locked 
resources L in the reference list with lower priority than 
resource R. For each resource L, the system traverses the 
derived list and unlocks any resource derived from these 
resources, step 704. The system next unlocks all locked 
resources in the derived list with lower priority than resource 
R, step 706. In step 708 the current task is placed in the wait 
list. In step 710 priority inheritance among the competing 
tasks is checked. The system then releases the semaphore 

20 and suspends execution, step 712. When resource R 
becomes available, and the task waiting for it is resumed, the 
system then re-acquires the semaphore and continues 
execution, step 714. In most cases, the system will continue 
execution from step 602 in the process outlined in FIG. 6. 

The aforementioned principles concerning multiple read/ 
single write functionality and deadlock detection (as 
opposed to prevention) apply equally to multiple record 
locking as single record locking. 

In the foregoing, a system has been described for provid- 
ing mutual exclusion of multiple tasks at the reconi level 

30 with priority inheritance and using one semaphore. Although 
the present invention has been described with reference to 
specific exemplary embodiments, it will be evident that 
various modifications and changes may be made to these 
embodiments without departing from the broader spirit and 

35 scope of the invention as set forth in the claims. Accordingly, 
the specification and drawings are to be regarded in an 
illustrative rather than a restrictive sense. 
What is claimed is: 

1. A method to be performed by a software routine that is 
^ comprised of a plurality of tasks that may desire to lock or 

unlock any of plurality of resources, said method compris- 
ing: 

maintaining a first list, said first list listing a first group of 
said tasks, wherein, each task listed within said first 
^5 group of tasks is waiting in a suspended state for at least 
one of said resources to be freed; 

maintaining a second list, said second list listing a second 
group of said tasks, wherein, each task listed within 
said second group of tasks is holding at least one of said 
50 resources; 

suspending a first task and expanding said first list to 
include said first task upon said first task desiring to 
lock a resource that is being held by a second task, said 
second task being listed on said second list, said first 
55 task having a priority, said resource having any one of 
a plurality of different levels; 

setting a flag to a first state as a consequence of said first 
task said desiring to lock said resource; 

comparing said priority of said first task with the priority 
60 of said second task; and 

increasing the priority level of said second task to that of 
said first task if said second task has a lower priority 
than said first task. 

2. The method of claim 1 wherein said second list further 
65 comprises a task name, an original priority level, and a 

current priority level for said each ta^ wittun said second 
group. 
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3. The method of claim 2 wherein said flag is a mutual 
exclusion semaphore. 

4. The method of claim 3 wherein said resource is a single 
data element represented as a record. 

5. The method of claim 3 further comprising allowing 5 
each single task of said plurality of tasks to access only one 
of said plurality of resources at a given time. 

6. The method of claim 3 further comprising: 
allowing each single task of said plurality of tasks to 

access a plurality of resources of said one or more 
resources at a given time; and 
assigning a priority level to each accessed resource held 
by a single task if said single task accesses more than 
one resource of said plurality of resources at said given 
time. IS 

7. The method of claim 1 fur±er comprising: 
determining whether a first resource of said plurality of 

resources contains a reference to a second resource of 
said plurality of references; and 
deriving said second resource from said reference if said 
first resource contains said reference. 

8. The method of claim 7 further comprising: 
storing, in a third Ust, an entry for each resource of said 

plurality of resources for which an explicit reference is ^ 
available; and 

storing, in a fourth list, an entry for each resource of said 
plurality of resources which is derived from a reference 
that is contained in another resource of said plurality of 
resources. 3q 

9. The method of claim 8 further comprising: 
identifying a highest priority imaccessed resource of said 

plurality of resources; 
locking said highest priority unaccessed resource; 
identifying additional resources of said plurality of •'^ 

resources referenced by said highest priority resource; 

and 

locking said additional resources. 

10. The method of claim 9 further comprising: ^ 
determining whether a locked resource of said additional 

resources cannot be locked; and 
unlocking all locked resources having an entry in said 
third list that have a priority level lower than said 
locked resource. 45 

11. The method of claim 1 further comprsing waving 
mutual exclusion policy if deadlock occurs between a third 
task and a fourth task of said plurality of tasks. 

12. The method of claim 11 further comprising reporting 
a system error. 

13. A method to be performed by a software routine that 
is comprised of a plurality of tasks that may desire to lock 
or unlock any of plurality of resources, said method com- 
prising: 

maintaining a first list, said first list listing a first group of 
said tasks, wherein, each task listed within said first 
group of tasks is waiting in a suspended state for at least 
one of said resources to be freed; 

maintaining a second list, said second list listing a second 
group of said tasks, wherein, each task listed within 
said second group of tasks is holding at least one of said 
resources; 

suspending a first task and expanding said first list to 
include said first task upon said first task desiring to 
lock a resource that is being held by a second task, said 
second task being listed on said second list, said first 
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task having a priority, said resource having any one of 

a plurality of different levels; 
setting a flag to a first state as a consequence of said first 

task said desiring to lock said resource; 
comparing said priority of said first task with the priority 

of said second task; and 
increasing the priority level of said second task to that of 

said first task if said second task has a lower priority 

than said first task. 

14. The method of claim 13 wherein said second list 
further comprises a task name, an original priority level, and 
a current priority level for said each task within said second 
group. 

15. The method of claim 14 wherein said flag is a mutual 
exclusion semaphore. 

16. The method of claim 15 wherein said resource is a 
single data element represented as a record. 

17. The method of claim 15 further comprising allowing 
each single task of said plurality of tasks to access only one 
of said plurality of resources at a given time. 

18. llie method of claim 15, further comprising: 
allowing each single task of said plurality of tasks to 

access a plurality of resources of said one or more 
resources at a given time; and 
assigning a priority level to each accessed resource held 
by a single task if said single task accesses more than 
one resource of said plurality of resources at said given 
time. 

19. The method of claim 13 further comprising: 
determining whether a first resource of said plurality of 

resources contains a reference to a second resource of 
said plurality of references; and 
deriving said second resource from said reference if said 
first resource contains said reference. 

20. The method of claim 19 further comprising: 
storing, in a third list, an entry for each resource of said 

plurality of resources for which an explicit reference is 
available; and 

storing, in a fourth list, an entry for each resource of said 
plurality of resources which is derived from a reference 
that is contained in another resource of said plurality of 
resources. 

21. The method of claim 20 further comprising: 
identifying a highest priority unaccessed resource of said 

plurality of resources; 
locking said highest priority unaccessed resource; 
identifying additional resources of said plurality of 

resources referenced by said highest priority resource; 

and 

locking said additional resources. 

22. The method of claim 21 further comprising: 
determining whether a locked resource of said additional 

resources cannot be locked; and 
unlocking all locked resources having an entry in said 
third list that have a priority level lower than said 
locked resource, 

23. The method of claim 13 further comprising waiving 
mutual exclusion policy if deadlock occurs between a third 
task and a fourth task of said plurality of tasks. 

24. The method of claim 23 further comprising reporting 
a system error. 

* * ♦ * * 
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